Method, system and program for direct client file access in a data management system

ABSTRACT

Provided is a method, system, and program implemented by a server for controlling and providing access to a file to at least one remote computer over a network. The server maintains metadata about files. The files are maintained at remote storage locations. The server receives a request from the remote computer for a filename of a requested file over the network. The server determines from the metadata one remote storage location address associated with the filename where the requested file is located. The server then updates the metadata for the requested file and sends the storage location address to the remote computer.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a method, system and program forproviding direct file access to a client in a data management system.

[0003] 2. Description of the Related Art

[0004] A source code management (SCM) system manages the source code ofsoftware projects, especially multi-programmer projects, trackingrevisions to the entire software system and making all product releasesconsistent. When multiple programmers work on the same project, one ofthe primary functions of an SCM system is to provide some form ofsynchronization control to prevent the same version of a source filefrom being modified simultaneously by more than one programmer. Evenwhen programmers or programming teams work in geographical isolationfrom each other, SCM systems are capable of merging individualmodifications to files and groups of files without causing conflicts.

[0005] Prior art SCM systems maintain a record of versions of files andother internal components of one or more software products. A record istypically kept with each set of changes of what the changes are, why thechanges were made, when the changes were made and who made the changes.Older versions can typically be recovered, and different versions can bemaintained simultaneously. Some SCM systems also facilitate the trackingof software product builds that encompass various phases such ascompiling, assembling, linking and so on. More advanced SCM systems canalso enforce additional process management mechanisms including accesscontrol, security, approval control for modifying source code and so on.Typical SCM systems known in the art include IBM ConfigurationManagement and Version Control (CMVC), Concurrent Versions System (CVS),Revision Control System (RCS), Source Code Control System (SCCS).

[0006] To provide an illustrative example, consider a software productbeing built by several teams of programmers working in geographicalisolation from each other. The source files that go into building thesoftware product are shared among the programming teams. During thecourse of development of the software product the files may have to bechanged several times, i.e., each file may have many versions. Inaddition, often multiple programmers may wish to make changes to thesame source code file at the same time. The changes to the files must bemade without causing any conflicts or disruptions to the process ofbuilding the software product. Typically, SCM systems ensure this byproviding for check-in and check-out control of source code files. Whenone programmer has checked-out a file to change the content the otherprogrammers cannot make any changes to the file. In other words, when afile is checked-out, the file is locked. Other programmers can of courseview the contents of the file with appropriate authority typicallyprovided by the SCM administrator or the SCM delegate. In a commonsituation only after the source code of the file has been changed and anew version of the file checked-in can the other programmers check-outthe file again. When a source file has been checked-out by oneprogrammer, other programmers wanting to view the content of the filecan extract the file. If a first programmer locks a file, no otherprogrammer can make changes to the file until the first programmer hasunlocked the file.

[0007] In typical prior art SCM systems, the process of limiting andauditing changes to files through the mechanism of checking files in andout is usually done by accessing a single central server, i.e. the SCMserver. A storage location referred to as “file storage” is connectedto, in proximity, and controlled by the SCM server. The programmersaccess the SCM server via SCM clients. All communications to accessfiles from an SCM client, such as check-out, check-in, extract etc. mustflow between the SCM client and the SCM server. In other words, existingSCM systems require the SCM client to access the correct version ofsource files only through communication with the SCM server. When an SCMclient wants to access a file, the SCM client sends a request to the SCMserver. The request specifies the name of the file. The name of the fileis referred to as “filename”. The SCM server locates the file in thefile storage and controls the SCM client access to the file. If therequest is for a check-out or extract the SCM server secures the filefrom the file storage and transmits the file to the SCM client. If therequest is for a check-in, the SCM server receives the file from the SCMclient and creates a new version of the file in the file storage. Sincefiles are often large, the time to transmit and receive files issignificant when compared to other activities within an SCM system. Inparticular, when the SCM clients are geographically dispersed and theSCM server is located across a Wide Area Network, the file access timesbetween the SCM clients and server can be significant.

SUMMARY OF THE PREFERRED EMBODIMENTS

[0008] Provided is a method, system, and program implemented by a serverfor controlling and providing access to a file to at least one remotecomputer over a network. The server maintains metadata about files. Thefiles are maintained at remote storage locations. The server receives arequest from the remote computer for a filename of a requested file overthe network. The server determines from the metadata one remote storagelocation address associated with the filename where the requested fileis located. The server then updates the metadata for the requested fileand sends the storage location address to the remote computer.

[0009] In one implementation, the server is a source code managementsystem server, and the remote computer is a source code managementsystem client and the network is built over the TCP/IP protocol.

[0010] In another implementation, the storage location addressidentifies a storage device that is at a geographical location closer tothe remote computer than a location of the metadata. Implementations areprovided where the request is for checking-out the file corresponding tothe filename, and this involves locking the requested file, returning aresponse code indicating that file check-out is successful, and updatingthe metadata indicating that the requested file is checked-out andlocked.

[0011] In further implementations, the server processes a pattern ofrequests for the filename received from the remote computer over time. Adetermination is made of one remote storage location based on thepattern of requests for the file name and the file corresponding to thefilename is stored at the storage location address that isgeographically closer to the remote computer. A correspondence is savedbetween the filename and the storage location address in the metadata.

[0012] The described implementations provide techniques for a server tostore files requested by remote computers at locations more proximate tothe remote computers to improve Input/Output (I/O) performance withrespect to files in the remote computers request from the server byreducing the distances the files must be transmitted between the remotecomputers and server.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention may be better understood, and its numerous objects,features, and advantages made apparent to those skilled in the art byreferencing the accompanying drawings. The use of the same referencesymbols in different drawings indicates similar or identical items.

[0014]FIG. 1 is a network diagram illustrating a computing environmentin which aspects of the invention are implemented;

[0015]FIGS. 2a and 2 b illustrate tables including information used toindicate the location of a file in accordance with implementations ofthe invention;

[0016]FIG. 3 is a flowchart illustrating the steps involved in the filestorage, SCM client and SCM server and their relationship to each otherin accordance with implementations of the invention;

[0017]FIGS. 4a and 4 b illustrate data structures for request andresponse in accordance with implementations of the invention;

[0018]FIG. 5 is a flowchart illustrating the steps in the SCM server inaccordance with implementations of the invention;

[0019]FIG. 6 is a flowchart illustrating requesting handling operationswithin the SCM server in accordance with implementations of theinvention;

[0020]FIG. 7 is a flowchart illustrating a check-out process at an SCMserver in accordance with implementations of the invention;

[0021]FIG. 8 is a flowchart illustrating the check-in process at an SCMserver in accordance with implementations of the invention;

[0022]FIG. 9 illustrates a an optimal file location update table inaccordance with implementations of the invention; and

[0023]FIG. 10 is a flowchart illustrating the optimal location of a fileat an SCM server based on the request patterns from SCM clients inaccordance with implementations of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] In the following description, reference is made to theaccompanying drawings which form a part hereof, and which illustrateseveral embodiments of the invention. It is understood that otherembodiments may be utilized and structural and operational changes maybe made without departing from the scope of the invention. FIG. 1depicts a network diagram illustrating a computing environment in whichaspects of the invention are implemented, and illustrates therelationship between an SCM server and SCM clients. An SCM Server 100 isconnected via Network 120 to SCM clients 130 and 140. SCM clients 130and 140 can be geographically separated by large distances. Thegeographical separation between SCM clients 130 and 140 is often presentwhen a software product is jointly developed in multiple software sitesthat are located in different cities or countries. The Network 120 maybe a Local Area Network (LAN), Internet, Intranet or any other type ofnetwork. A variety of protocols such as Hypertext Transfer Protocol(HTTP), File Transfer Protocol (FTP), Wireless Application Protocol(WAP) etc. can be used to communicate across Network 120. In addition,storage for file control metadata 300 is also connected via LAN 150 toSCM server 100. File control metadata 300 is a set of data structuresthat contain various attributes and properties of files. The sourcefiles of a software product are not stored in the file control metadata300 but are resident elsewhere in the network 120.

[0025] SCM client 130 is connected to file storage 330 and both are partof subnet 350. Similarly, SCM client 140 is connected to file storage340 and both are part of subnet 360. file storage 330 and 340 are alsoconnected to Network 120 such that SCM server 100 can communicate withfile storage 330 and 340. Communication between SCM server 100 and filestorage 330 and 340 is relatively slow. However, the communicationbetween SCM client 130 and file storage 330 is relatively fast becauseboth SCM client 130 and file storage 330 are part of the same subnet.The same is the case with regard to relatively high communication speedbetween SCM client 140 and file storage 340. The actual files are storedin file storage 330 and file storage 340 whereas the file controlmetadata 300 stores the various attributes and properties of the files.SCM client 130 can secure files from file storage 330 relatively quicklybut can secure files from file storage 340 relatively slowly. Thecommunication between SCM client 130 and file storage 340 is across therelatively slow Network 120. The file storage 330 and 340 can be part ofa Storage Area Network (SAN) or a Network Attached Storage (NAS).

[0026] For illustrative purposes the IP address “123.46.83.137” denotedby reference numeral 370 is shown associated with file storage 330. Thisis the network address of file storage 330. Alternatively, the filestorage can be addressed using a host name, sharename, etc.

[0027]FIGS. 2a,b illustrate tables 470, 480, respectively, representingthe file control metadata 300. File control metadata 300 includesinformation used to indicate the location of a file in accordance withimplementations of the invention. The tables 470, 480 are part of thedata structures of the file storage metadata 300. Other data structurescan also be used to represent the file control metadata 300. The tableshown in FIG. 2a has three columns. The first column contains thefilename 400; the second column contains the file location 410, referredto as location of file; and the third column contains the status of file420. An illustrative name for a file “OS2/windowapplication/base.c” 430is shown. The location of file 430 is at“//123.46.83.137/home/application1/134.c” 440 and the status of file 430is “Unlocked” 450. The entry reflected under the location of file entryis referred to as storage location address. In this particular example,“//123.46.83.137/

[0028] home/application1/134.c” 440 is the storage location address. Apossible illustrative interpretation of this can be as follows. The file“base.c” located in directory “OS2/windowapplication” in the softwareproduct source code is physically located at IP address “123.46.83.137”in directory “home/application1” and is named “134.c”. Note that in FIG.1, file storage 330 had the same IP address. Hence, “base.c” is storedas file “134.c” in file storage 330 with appropriate directories. SCMclients 130 and 140 refer to the files by the filename 400 when SCMclients 130 and 140 make a request to the SCM server 100. However, theSCM server 100 stores the actual physical file in the above example inIP address “123.46.83.137”. The tables 470 or 480 in the file controlmetadata 300 contain the mapping of the filename 400 to the location offile 410. The file in the example shown in FIG. 2a is “Unlocked” 450 andhence the file can be checked-out by SCM clients 130 or 140. FIG. 2b issimilar to FIG. 2a except that FIG. 2b shows that the Status of file 420has changed to “Locked by SCM Client 130” 460. This state occurs whenthe SCM Client 130 has checked-out the file. A locked file is typicallynot available for check-out by another SCM client 130, 140. However, thelocked file can be provided for file extract and a variety of otheroperations.

[0029]FIG. 3 is a flowchart illustrating operations occurring in thefile storage 330, the SCM client 130 and the SCM server 100, and theirrelationship to each other. The process starts at block 515 and proceedsto block 520 where the SCM client 130 generates a request. The SCMserver 100 receives the request (at block 525). The SCM server 100determines (at block 530) whether satisfying the request involvessending or receiving a file. If the answer is yes, then the location ofthe file for the SCM client 130 is determined (at block 545). It ispossible in alternative implementations to have more than one locationof the file when the file is stored in multiple locations and thecorresponding management performed by the file control metadata 300.When there is more than one location of the file, the one that isgeographically closest to the SCM client 130 is determined. By referringback to FIG. 2 if SCM client 130 had requested a check-out of“OS2/windowapplication/base.c”, then the SCM server 100 consults thefile control metadata 300 and from the table 470 indicated in FIG. 2adetermines that the location of file “OS2/window application/base.c” isin “//123.46.83.137/home/application1/134.c”. The location of the fileis added (at block 550) to the response to the SCM client 130. Theresponse is sent (at block 555) to the SCM client 130. In case theresponse in decision box 530 is “no” then no file needs to betransferred. In such case, a response is sent (at block 555) to the SCMclient without indicating any file location.

[0030] The SCM client 130 receives (at block 560) the response to therequest from the SCM server 100. The SCM client 130 determines (at block565) whether the response contains the location of a file. If yes, thenthe SCM client 130 generates (at block 580) a request to file storage330 for the file. In case the SCM client 130 had requested a check-outof “OS2/windowapplication/base.c”, then the request for the actualcontent of the file would go to file storage 330, which is at TCP/IPaddress 123.46.83.187, which includes the requested file. In alternativeimplementations, the SCM server 100 can directly request file storage330 to communicate with the SCM client 130 and in such a situation theSCM client 130 does not have to generate an explicit request to the filestorage 330. The file storage 330 receives (at block 585) the requestand allows (at block 590) the SCM client 130, 140 access to the file. Anappropriate response code may be sent by the file storage 330 to the SCMclient 130 indicating the status of responsiveness to the request fromthe SCM client 130. The SCM client 130 sends or receives (at block 595)the file as the case may be. The SCM client completes the receipt (orsending) and stops processing (at block 598). Note that if the responsedoes not contain the location of a file (at block 565), then the SCMclient continues in the next step to block 598 and stops operation forthe request.

[0031] With the described implementations, the SCM client 130 sends andreceives the file in less time when compared to transmitting the filedirectly to the SCM server 100. By storing the file proximate to the SCMclient 130, file transfer operations occur substantially faster andconsume less long distance network bandwidth. Proximate, as that term isused herein, implies that the file is geographically close, such aswithin the same facility or city as the requesting SCM client 130. Thefile transfer time is a substantial contributor to system latency andperformance delays. The described implementations provide significantimprovements in the file transfer time and, hence, reduce latency.

[0032]FIGS. 4a and 4 b illustrate data structures for request andresponse in accordance with implementations of the invention. FIG. 4ashows the data structure corresponding to an SCM client request 600 anda sample SCM client request 630. The SCM client request 600 has twofields—the request code 610 and the filename 400. Note that filename 400is provided in the tables 470, 480 in FIGS. 2a,b and refers to the namecorresponding to a file referred to by an SCM client 130,140. Anillustrative example of the sample SCM client request 630 shows therequest code 610 as Check-out 640 and the Filename 400 as“/os2/windowapplication/base.c” 430. The example is similar to thatdescribed in FIGS. 2a and 2 b. FIG. 4b shows the response data structurecorresponding to an SCM server response 660 and a sample SCM serverresponse 670. The SCM server response 660 has two fields—the Responsecode 680 and the Location of file 410 (Location of File 410 wasdescribed in FIGS. 2a,b). An illustrative example shows the Responsecode 680 as “Check-out OK” 690 and the Location of file as“//123.46.83.137/home/application1/134.c” 440. The example is similar tothat described in FIGS. 2a and 2 b.

[0033]FIG. 5 is a flowchart showing the steps in the SCM server 100 inaccordance with the described implementation of the invention using thedata structures shown in FIGS. 2a,b and FIGS. 4a,b. The process startswith the SCM server 100 waiting (at block 700) for a request. The SCMserver 100 receives (at block 705) a request 600, 630 (FIG. 4a) from anSCM client. The SCM server 100 parses the request for request code 610and filename 400 (at block 710). SCM server 100 determines if there is afilename in the request (at block 715). If there is a filename then anaction is taken corresponding to the request code 610 (at block 735).After executing block 735, the process that executes the optimal filelocation routine is executed (described below in FIGS. 9, 10) with thename identifying the SCM client and the filename 400 as parameters (atblock 736). The optimal file location routine updates data structuresincluding the file control metadata 300 based on the history of requestpatterns arriving from SCM clients 130,140 for file access, such thatthe location of file corresponding to a filename is appropriate. This isdescribed below in FIGS. 9, 10. Following block 736, the file controlmetadata 300 is consulted and the location of file is determined fromthe filename as described earlier in FIGS. 4a,b and the data structureswithin the file control metadata 300 are updated (at block 740). Thenthe SCM server 100 responds (at block 750) with response code 680 andlocation of file 410 to the SCM client 130 and goes back to waiting (atblock 700) for the next request. In case there is no filename in theclient request the SCM server 100 takes action corresponding to Requestcode 610 and updates (at block 725) the file control metadata 300. SCMserver 100 then sends (at block 745) the SCM server response 660 withthe location of file 410 as NULL. Processing then continues with the SCMserver 100 waiting (at block 700) for the next request.

[0034]FIG. 6 is a flowchart showing how different types of requests froma client are handled within the SCM server 100. The process starts withthe SCM server 100 waiting (at block 800) for a request. When SCM server100 receives (at block 805) the request, SCM server 100 determines (atblock 810) the request type. Six common request types are shown in theFIG. 6. In case the request types are check-out 820, extract 825, orcheck-in 830, the file control metadata 300 is updated and the locationof the file to be accessed is sent (at block 845) to the SCM client 130with the response. When the file is checked out the file is labeled aslocked in the file control metadata 300. In the case of extract 825 thefile is not labeled as locked. Extract 825 is for read-only access to afile by an SCM client 130. In the case of check-in 830, the file must besent from the SCM client 130. In the case of check-in 830, after the SCMserver 100 receives the filename, the SCM server 100 will determine theoptimum location to store the file and will ask the SCM client 130 tostore the file in such a location. In certain implementations, the filewill be stored at one or more locations where the file is mostgeographically proximate to SCM clients most likely to request the file.Additional details are described in FIGS. 9 and 10. In case the requestsare for lock 815, unlock 835, delete 840, then the appropriatesubroutine is called, and the file control metadata 300 is updated andthe response is sent (at block 850) to the SCM client 130. Lock 815locks a file; unlock 835 unlocks a file; and delete 840 deletes a file.In the case of lock, unlock or delete the SCM client 130 does not needaccess to the actual file. The update of the file control metadata 300is adequate. The steps of the subroutine for check-out and check-in aredescribed below in FIGS. 7 and 8. Control proceeds from block 845 orblock 850 to block 800 where the process waits for the next request froman SCM client 130, 140.

[0035]FIG. 7 is a flowchart illustrating logic for the check-outsubroutine 820 executed in the SCM server 100. First the check-outsubroutine is initialized (at block 900). Then a decision is made as towhether the filename is locked (at block 905). If the filename is lockedthen the file corresponding to the filename cannot be checked-out.Processing therefore continues to block 910 wherein a response code 680corresponding to check-out not OK is generated. In contrast, if thefilename is not locked, the file is locked (at block 915) and the actualfile is determined from the filename by examining 300 (at block 920) thefile control metadata. A response code 680 corresponding to check-out OKis generated (at block 925) and the process comes to a stop (at block930). Subsequently block 845 is executed as shown in FIG. 6. FIG. 7 isdrawn from the SCM server 100 perspective and contains the stepsundergone at the server.

[0036]FIG. 8 is a flowchart illustrating the logic of the check-insubroutine 830. First, the check-in subroutine is initialized (at block1000). A decision is made (at block 1005) as to whether the filename islocked by some other SCM client besides the requesting SCM client 130.If the filename is locked by some other SCM client other than therequesting SCM client 130, then the file corresponding to the filenamecannot be checked-in. Processing therefore continues such that theresponse code 680 corresponding to check-in not OK is generated (atblock 1025). In contrast, if the file name is not locked by some otherSCM client, then the location of the file is determined (at block 1020)from the filename by examining the file control metadata 300. A responsecode 680 corresponding to check-in OK is generated (at block 1030), thefilename is unlocked (at block 1035) and the process comes to a stop (atblock 1040). Check-in of a file by an SCM client 130 can occur onlyafter an SCM client 130 has locked the file. Check-in of a file adds afile with a new version number. At a later stage of processing (notshown in FIG. 8), the SCM client 130 utilizes the location of the fileto check-in the actual file. Additional actions may be taken in theevent that the SCM client 130 is unable to access the location of thefile because the file storage 330 is not functional. The methods can bemodified to take account of such unusual situations. Another commandsimilar to check-in is create. Create is typically used when a file iscreated for the very first time.

[0037]FIG. 9 illustrates an optimal file location update table 1100,providing a data structure used by the SCM server to maintain statisticspertaining to the optimal location of a file. The optimal file locationupdate table 1100 can be maintained either at the SCM server 100 or asan adjunct to the file control metadata 300. The table headings arefilename 400, number of accesses by SCM client 130 (labeled by referencenumeral 1105), number of accesses by SCM client 140 (labeled byreference number 1110), and file storage location 1115. According to thetable 110, the file “/os2/windowapplication/base.c” 430 has beenaccessed 5127 (reference numeral 1125) times by SCM client 130 and once(reference numeral 1130) by SCM client 140 and hence file storage 330which is proximate SCM Client 130 stores the file corresponding to“/os2/windowapplication/base.c”. Likewise, in a similar manner file“/os2/kernel/main.c” is kept in file storage 340 (as denoted in optimalfile location update table 1100 by reference numeral 1135) which isproximate to SCM client 140. The number of accesses by a particular SCMclient is incremented each time an access occurs. Other schemes fordetermining where to store a file are possible. In many situations afile can be stored not just proximate to one SCM client, but can bestored in multiple locations such that the file is proximate to multipleSCM clients.

[0038]FIG. 10 is a flowchart illustrating logic implemented in the SCMserver 100 showing how the optimal location of a file can be updated atthe SCM server 100 based on the request patterns from SCM clients. Theprocess waits for input in block 1200. The SCM server 100 receives (atblock 1205) the SCM client identifier corresponding to the request of anSCM client 130 to the SCM server 100 and the filename 400 (for example,“/os2/windowapplication/base.c” 430) contained in the request. The SCMserver 100 then increments the appropriate table entry 1125 in the filelocation update table 1100 (at block 1210). The table entry 1125corresponding to the filename 400 (“/os2/windowapplication/base.c” 430)and SCM client 130 reflects that the particular filename has beenrequested for access by an SCM client 130 one more time than before. TheSCM server 100 continues to determine whether the table entry 1125 afterthe update exceeds the access requests by other SCM clients of the samefile (at block 1215). If the number of requests by the SCM client doesnot exceed the maximum number of request in the table entry 1128, theSCM server 100 determines (at block 1215) whether the number of requestsfrom the client would become larger than the number of requests in thetable entry 1225 after the increment. If the number of requests for thefile by the requesting client does not exceed the value in the tableentry 1128, the process stops (at block 1240). Otherwise, the filestorage location 1115 is updated in the optimal file location updatetable 1100, and the file stored (at block 1230) in the correspondingstorage location address. Block 1230 may be performed at periodicintervals say on a weekly or daily basis rather than immediately at theconclusion of block 1215 in order to avoid using substantial networkbandwidth and other resources to frequently move the file to differentlocations. The file storage location is chosen to be proximate to theSCM client based on the configuration of the overall network. The filestorage location is selected to minimize a distance the requested fileis transmitted between each SCM client and the file storages based onthe number of requests for the file from each SCM client.

[0039] File control metadata 300 is updated to reflect the properfilename and location of file (at block 1235). The process then comes toa stop (at block 1240). The file is stored in one place only in theabove implementation. However, other implementations can be constructedwhere the file is stored in multiple location.

Additional Implementation Details

[0040] The described implementations may be implemented as a method,apparatus or article of manufacture using standard programming and/orengineering techniques to produce software, firmware, hardware, or anycombination thereof. The term “article of manufacture” as used hereinrefers to code or logic implemented in hardware logic (e.g., anintegrated circuit chip, Field Programmable Gate Array (FPGA),Application Specific Integrated Circuit (ASIC), etc.) or a computerreadable medium (e.g., magnetic storage medium (e.g., hard disk drives,floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks,etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs,PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code inthe computer readable medium is accessed and executed by a processor.The code in which preferred embodiments are implemented may further beaccessible through a transmission media or from a file server over anetwork. In such cases, the article of manufacture in which the code isimplemented may comprise a transmission media, such as a networktransmission line, wireless transmission media, signals propagatingthrough space, radio waves, infrared signals, etc. Of course, thoseskilled in the art will recognize that many modifications may be made tothis configuration without departing from the scope of the presentinvention, and that the article of manufacture may comprise anyinformation bearing medium known in the art.

[0041] Many of the examples provided have shown only source files beingaccessed. However, in most SCM systems binary files can be equallyaccessed in an equivalent manner and the invention encompasses theaccess methods and access patterns for binary files, documentationfiles, comment files and any other types of file that are present in SCMsystems.

[0042] While the invention has been described with an SCM system havingcheck-in, check-out, delete, extract, lock and unlock procedures theremay be other procedures that can be implemented in a manner equivalentto that described in the invention. For example, many SCM systems havecomplex procedures for release and component management. The fileaccesses involved for such processes are also covered by the invention.Similarly, multiple files can often be requested by an SCM client in asingle command and this can be accommodated into the invention.

[0043] While the invention has been described as potentially updatingthe file storage location at every request, variations can beconstructed where the file storage location is updated only at periodicintervals, possibly on a daily or weekly basis. Similarly, the inventionhas been described with a file being stored in one file storagelocation. However, variations can be constructed where the same file isstored in multiple file storage locations and this is included withinthe scope of the invention. The invention has described the situationwhere the SCM clients request access to the file from the proximate filestorage. In alternative implementations the SCM server could request thefile storage to directly interact with the SCM client. In such asituation the file storage could directly send or receive files to orfrom the SCM client.

[0044] In certain implementations, the SCM client and SCM may be part ofan integrated software system. For example, in the SCM system known asCMVC there are CMVC servers and CMVC clients. However, all SCM clientsneed not have similar internal software implementations. It is possiblefor dissimilar SCM clients produced by different entities tointeroperate with an SCM server. The invention encompasses suchscenarios. In addition, we have not discussed in detail how SCM clientscan access files. The access can be achieved by distributed file systemssuch as Andrew File System (AFS) or Common Internet File System (CIFS).Clients can also access files by protocols such as FTP, HTTP, or WAP.

[0045] The foregoing description of the preferred embodiments of theinvention has been presented for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise form disclosed. Many modifications andvariations are possible in light of the above teaching. It is intendedthat the scope of the invention be limited not by this detaileddescription, but rather by the claims appended hereto. The abovespecification, examples and data provide a complete description of themanufacture and use of the composition of the invention. Since manyembodiments of the invention can be made without departing from thespirit and scope of the invention, the invention resides in the claimshereinafter appended.

What is claimed is:
 1. A method for controlling and providing access toa file to at least one remote computer over a network, comprising:maintaining metadata about files maintained at remote storage locations;receiving a request from the remote computer for a filename of arequested file over the network; determining from the metadata oneremote storage location address associated with the filename where therequested file is located; updating the metadata for the requested file;and sending the storage location address to the remote computer.
 2. Themethod of claim 1, wherein the remote computer is a source codemanagement system client.
 3. The method of claim 1, wherein the storagelocation address identifies a storage device that is at a geographicallocation closer to the remote computer than a location of the metadata.4. The method of claim 3, wherein the request is for checking-out therequested file corresponding to the filename, and further comprising:locking the requested file; returning a response code to the remotecomputer indicating that file check-out is successful; and updating themetadata indicating that the requested file is checked-out and locked.5. The method of claim 3, wherein the request is for checking-in therequested file corresponding to the filename, and further comprising:updating the metadata indicating the requested file is unlocked; andreturning a response code indicating that the file check-in issuccessful.
 6. The method of claim 1, further comprising: processing apattern of requests for the file received from remote computers atdifferent geographical locations; determining one of a plurality ofremote storage locations based on the pattern of requests for the file;storing the file corresponding to the file at the determined remotestorage location; and saving a correspondence between the file and thestorage location address in the metadata.
 7. The method of claim 6,wherein the determined remote storage location is at a geographicallocation that is more proximate to the remote computer having morerequests for the file than other remote computers.
 8. The method ofclaim 6, wherein the determined remote storage location is selected fromthe plurality of remote storage locations to minimize a distance therequested file is transmitted between each remote computer and theremote storage location based on the number of requests for the filefrom each remote computer.
 9. The method of claim 1, wherein the remotecomputer is a source code management system client, and the request isone of check-in, check-out, extract, lock, unlock, delete.
 10. A methodfor accessing a file in a source code management system, comprising:sending a first request for a file; receiving a storage location addresscontaining the file in response to the first request; sending a secondrequest to the storage location address; and receiving an access to thefile from the storage location address.
 11. The method of claim 10,wherein the first request is for checking-out the file, and furthercomprising: downloading the file from the storage location address. 12.The method of claim 10, wherein the first request is for checking-in thefile, and further comprising: sending a new version of the file to thestorage location address.
 13. The method of claim 10, furthercomprising: receiving a first response code from a remote computer inresponse to the first request; and receiving a second response code fromthe storage location in response to the second request.
 14. A system forcontrolling and providing access to a file to remote computers over anetwork, wherein remote storage locations are accessible over thenetwork, comprising: metadata including information about files at theremote storage locations; means for receiving a request from one remotecomputer for a filename of a requested file over the network; means fordetermining from the metadata one storage location address of one remotestorage location associated with the filename where the requested fileis located; means for updating the metadata for the requested file; andmeans for sending the remote storage location address to the remotecomputer.
 15. The system of claim 14, wherein the remote computer is asource code management system client.
 16. The system of claim 14,wherein the storage location address identifies a storage device that isat a geographical location closer to the remote computer than a locationof the metadata.
 17. The system of claim 16, wherein the request is forchecking-out the requested file corresponding to the filename, andfurther comprising: means for locking the requested file; means forreturning a response code to the remote computer indicating that filecheck-out is successful; and means for updating the metadata indicatingthat the requested file is checked-out and locked.
 18. The system ofclaim 16, wherein the request is for checking-in the requested filecorresponding to the filename, and further comprising: means forupdating the metadata indicating the requested file is unlocked; andmeans for returning a response code indicating that the file check-in issuccessful.
 19. The system of claim 14, further comprising: means forprocessing a pattern of requests for the file received from remotecomputers at different geographical locations; means for determining oneof a plurality of remote storage locations based on the pattern ofrequests for the file; means for storing the file corresponding to thefile at the determined remote storage location; and means for saving acorrespondence between the file and the storage location address in themetadata.
 20. The system of claim 19, wherein the determined remotestorage location is at a geographical location that is more proximate tothe remote computer having more requests for the file than other remotecomputers.
 21. The system of claim 19, wherein the determined remotestorage location is selected from the plurality of remote storagelocations to minimize a distance the requested file is transmittedbetween each remote computer and the remote storage location based onthe number of requests for the file from each remote computer.
 22. Thesystem of claim 14, wherein the remote computer is a source codemanagement system client, and the request is one of check-in, check-out,extract, lock, unlock, delete.
 23. A system for accessing a file in asource code management system, comprising: means for sending a firstrequest for a file; means for receiving a storage location addresscontaining the file in response to the first request; means for sendinga second request to the storage location address; and means forreceiving an access to the file from the storage location address. 24.The system of claim 23, wherein the first request is for checking-outthe file, and further comprising: means for downloading the file fromthe storage location address.
 25. The system of claim 23, wherein thefirst request is for checking-in the file, and further comprising: meansfor sending a new version of the file to the storage location address.26. The system of claim 23, further comprising: means for receiving afirst response code from a remote computer in response to the firstrequest; and means for receiving a second response code from the storagelocation in response to the second request.
 27. An article ofmanufacture including code for controlling and providing access to afile at storage locations on a network to at least one remote computerover the network, wherein the code is capable of causing operationscomprising: maintaining metadata about files maintained at remotestorage locations; receiving a request from the remote computer for afilename of a requested file over the network; determining from themetadata one remote storage location address associated with thefilename where the requested file is located; updating the metadata forthe requested file; and sending the storage location address to theremote computer.
 28. The article of manufacture of claim 27, wherein theremote computer is a source code management system client.
 29. Thearticle of manufacture of claim 27, wherein the storage location addressidentifies a storage device that is at a geographical location closer tothe remote computer than a location of the metadata.
 30. The article ofmanufacture of claim 29, wherein the request is for checking-out therequested file corresponding to the filename, and further comprising:locking the requested file; returning a response code to the remotecomputer indicating that file check-out is successful; and updating themetadata indicating that the requested file is checked-out and locked.31. The article of manufacture of claim 29, wherein the request is forchecking-in the requested file corresponding to the filename, andfurther comprising: updating the metadata indicating the requested fileis unlocked; and returning a response code indicating that the filecheck-in is successful.
 32. The article of manufacture of claim 27,further comprising: processing a pattern of requests for the filereceived from remote computers at different geographical locations;determining one of a plurality of remote storage locations based on thepattern of requests for the file; storing the file corresponding to thefile at the determined remote storage location; and saving acorrespondence between the file and the storage location address in themetadata.
 33. The article of manufacture of claim 32, wherein thedetermined remote storage location is at a geographical location that ismore proximate to the remote computer having more requests for the filethan other remote computers.
 34. The article of manufacture of claim 32,wherein the determined remote storage location is selected from theplurality of remote storage locations to minimize a distance therequested file is transmitted between each remote computer and theremote storage location based on the number of requests for the filefrom each remote computer.
 35. The article of manufacture of claim 27,wherein the remote computer is a source code management system client,and the request is one of check-in, check-out, extract, lock, unlock,delete.
 36. A article of manufacture including code for accessing a filein a source code management system, wherein the code is capable ofcausing operations comprising: sending a first request for a file;receiving a storage location address containing the file in response tothe first request; sending a second request to the storage locationaddress; and receiving an access to the file from the storage locationaddress.
 37. The article of manufacture of claim 36, wherein the firstrequest is for checking-out the file, and further comprising:downloading the file from the storage location address.
 38. The articleof manufacture of claim 36, wherein the first request is for checking-inthe file, and further comprising: sending a new version of the file tothe storage location address.
 39. The article of manufacture of claim36, further comprising: receiving a first response code from a remotecomputer in response to the first request; and receiving a secondresponse code from the storage location in response to the secondrequest.